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DECISION ON APPEAL 



1 Filed June 20, 2001, titled "System and Method for Analyzing 
Statistics in a Reporting System." 

2 The two-month time period for filing an appeal or commencing a 
civil action, as recited in 37 C.F.R. § 1.304, begins to run from the decided 
date shown on this page of the decision. The time period does not run from 
the Mail Date (paper delivery) or Notification Date (electronic delivery). 
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This is a decision on appeal under 35 U.S.C. § 134(a) from the final 
rejection of claims 1-27 and 29. Claims 28 and 30 are objected to. 3 
We have jurisdiction pursuant to 35 U.S.C. § 6(b). 

An oral hearing was held on April 23, 2009. 

We affirm. 

STATEMENT OF THE CASE 

The invention 

The invention is described in the context of a reporting system such as 
the Online Analytical Processing (OLAP) decision support system (DSS) 
shown in Figure 1. Analysts, managers, and other users may query or 
interrogate a plurality of databases to extract demographic, sales and/or 
financial data and information and other patterns from records stored in the 
databases to identify strategic trends (Spec. 4: 19-22). A user engine 102 
communicates with an analytical engine 104 which communicates with a 
query engine 106 which in turn interfaces with data storage devices 108a, 
108b, . . . , 108n (Spec. 5: 9-21). The analytical engine 104 may process 



3 Although the Examiner's Answer's Statement of the Rejection states 
that claim 28 is rejected under the written description requirement of 
35 U.S.C. § 112, first paragraph, (Ans. 4), the Response to Argument section 
states that the rejection is withdrawn (Ans. 7). Appellants requested 
clarification in the Reply Brief, but the Examiner did not respond when 
acknowledging the Reply Brief. We assume that the § 112 rejection is 
withdrawn and that claim 28 is objected to. 
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queries to generate an quantitative report 110 indicating the results 114 from 
the storage devices 108 (Spec. 9: 4-6). 

The invention provides for capturing relevant statistics and data to 
enable profiling and/or understanding of current and historical activity of the 
reporting system (Spec. 11: 7-8). As explained in the Specification: 

A system administrator may use statistics to monitor, configure, 
and tune a system. Statistics may enable analyses of system 
performance, indicate application usage and allow optimization of 
configurations within the system, as well as answer various questions 
regarding these topics. Statistics may be used for other analysis as 
well. 

Analysis of system performance may include monitoring the 
status of the server. . . . Analysis of system performance may also 
include linking with other performance metrics (e.g., via a 
performance monitor), understand caching effectiveness, 
understanding datamart effectiveness, understanding scheduling 
effectiveness, and tuning structural query language (SQL). According 
to an embodiment of the invention, statistics may enable an 
administrator to answer questions regarding system performance, 
including identifying system bottlenecks, whether an additional server 
should be added, whether server functions may be spread over 
multiple machines, how a metadata database server is impacting the 
system, and whether the metadata database should be moved to a 
separate machine. According to an embodiment of the invention, 
automated tuning of the report system may occur based on statistics 
and statistics reports. Automated tuning may include, but is not 
limited to, adding or removing resources from an analytical engine or 
a query engine. Other analysis and questions may also be performed 
and determined. 

Indicating application usage may include indicating report 
and/or document usage, user activity, such as drill-downs and 
prompts, user access patterns (e.g., time of day, day of month, etc.), 
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billing functions, such as system resources used by a user and other 
usage. According to an embodiment of the invention, statistics may 
enable an administrator to answer questions regarding application 
usage, including what tables a query is hitting, what additional 
aggregate tables are needed, whether a larger percentage of reports 
should be cached, what reports/objects are being used, what does the 
query access pattern look like, where does the database need tuning, 
and how could reports be designed more efficiently. Statistics may 
also include information on actions taken by a subscriber upon 
receiving a report from the reporting system. Actions may include, 
but are not limited to, deleting a report, accessing the report, 
forwarding the report and instructing a transaction based on the report. 
Other analysis and questions may also be performed and determined. 

Spec. 12:17 to 14: 6. 

The claims 

Claim 1 is reproduced below: 

1 . A computer-implemented method for capturing at least one 
statistic or data regarding performance operation of a business 
intelligence reporting system that generates business intelligence 
reports based on requests submitted to perform analysis of data 
contained in a database, the method comprising the steps of: 

gathering at least one statistic or data related to the performance 
operation of the reporting system while the reporting system is 
operating; 

analyzing the at least one statistic or data; and 

generating at least one output based on the gathered at least one 
statistic or data, wherein the at least one output includes an alert if the 
analysis of the at least one statistic or data indicates that a condition 
has occurred. 
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The references 

Hayes US 2002/0046204 Al Apr. 18, 2002 

(based on provisional application filed Aug. 25, 2000) 

Hahn et al., Capacity Planning for Business Intelligence Applications: 
Approaches and Methodologies, document SG24-5689-00, 
November 2000 ("Hahn"). 

IBM OS/390 Resource Measurement Facility Report Analysis 6th ed., 
document SC28- 1950-05, September 2000, pages: cover through 
xxvii, 1-1 through 1.7, 2-240 through 2-262, and 5-1 through 5-52 
("IBM1"). 

The rejections 

Claims 1-8, 10-17, 19-26, and 29 stand rejected under 35 U.S.C. 
§ 102(a) as anticipated by the IBM Business Intelligence infrastructure 
accessing DB2 on OS/390 (IBM) as described in Hahn and IBM1. 

Claims 9, 18, and 27 stand rejected under 35 U.S.C. § 103(a) as 
unpatentable over IBM as described in Hahn and IBM1, in view of Hayes. 

FACTS 

Hahn (describing the IBM system) 

Hahn describes approaches and methodologies for capacity planning 
of the system resources that support Business Intelligence (BI) applications 
accessing DB2 on OS/390 (p. 1). 

"Business Intelligence (BI) is the gathering and analysis of vast 
amounts of data in order to gain insights that drive strategic and tactical 
business decisions which, in turn, will improve performance in the market 
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place." P. 1. "The purpose of Business Intelligence systems is to support 
the processing that transforms data into actionable information. Some 
common BI applications include market segmentation, customer profiling, 
campaign analysis, fraud detection, risk analysis and profitability analysis." 
Id. 

Raw data is collected, and "transformed and stored into a single 
database format, such as DB2, for query access and analysis" (p. 4). 

The three most common techniques of data analysis are "Query and 
Reporting," "On-Line Analytical Processing (OLAP)," and "Data mining" 
(p. 5). Since Appellants mention an OLAP reporting system, we note the 
following description in Hahn: "On-Line Analytical Processing (OLAP) - 
This is the analysis of precalculated, summarized data in multiple 
dimensions and business views. This technique is used, for example, to gain 
insights into how events occur over time. OLAP can answer questions like, 
which branch office was most profitable in January?" Id. Nevertheless, a BI 
system could use any technique of data analysis unless specifically limited; 
e.g., claim 8 recites that "the reporting system is an OLAP system." 

The S/390 Business Intelligence infrastructure is all the hardware and 
software that support the BI system, including the Data Base Management 
System (DBMS) software, the operating system environment, the physical 
hardware resources that support the movement, storage, formatting, and 
altering of data, and the DB2 on OS/390 database management system, the 
OS/390 operations system, S/390 processors, memory, and I/O channels, as 
well as controllers and disk (p. 8). 
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The purpose of "capacity planning" is "to estimate the computer 
resources required to meet an application's service level objectives over 
time" (p. 9). "Capacity planning utilizes measurement tools to understand 
the resource usage of the current workload, together with the collection of 
feedback from business users, in order to understand future requirements as 
they relate to the expected growth in data and users, changing data access, 
and performance requirements." Id. 

Hahn describes capacity planning for BI workloads: 

S/390 system measurement tools (such as System Management 
Facility, Resource Management Facility, and DB2 Performance 
monitor traces and reporting capabilities) can be utilized to capture 
the performance and resource consumption characteristics of the 
existing workload and apply proven guidelines and methods to 
approximate the future growth in resource requirements based on 
projected growth of the workload. [Emphasis added.] 

P. 12. The "workload" is the BI workload, i.e., the BI reporting system. 

Capacity planning is focused on gathering information to answer, for 
example, the questions: "Which Information Technology (IT) resources are 
currently in use? (CPU, CF, devices, controllers, channels, coupling links, 
storages and so forth)" (p. 13) and "Which parts of the workloads consume 
the most resources" {id.). 

Chapter 4, "Characterization of existing workloads," discusses 

characteristics of BI workloads. Hahn states: 

To plan for added capacity in a business intelligence environment, it is 
first necessary to determine the current resource consumption of the 
workload, and to relate it to the variables of the workload. The 
metrics to consider for a workload include the users, the number and 
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type of queries they generate, the processing capacity they require, 
and the amount of data stored and accessed in the system. 

P. 53. In particular, Hahn describes: (1) profiling system usage of a 
workload (Sec. 4.2.2), i.e., the capacity requirements of an application over 
time, such as the average to peak utilization ratio (Fig. 8) and various BI 
application profiles (e.g., OLAP types, simple report writing (Fig. 9); 
(2) profiling data use associated with the application, such as data volume 
and data access patterns (Sec. 4.2.3); (3) profiling the users, such as the 
number of users that concurrently execute queries in the system (Sec. 4.2.4); 
(4) profiling the queries by the type of query and the business unit to whom 
the users belong (Sec. 4.2.5). All of these profiles deal with statistics and 
data on the BI reporting system while it is operating. 

Hahn describes that an application may be "tuned" to increase 
performance (pp. 33-34). Hahn states: 

In a BI workload, tuning can have a dramatic impact on resource 
consumption. . . . Most query performance challenges are due to poor 
access paths or the volume of data requested. A majority of CPU 
savings is realized from tuning access paths, in some cases, by orders 
of magnitude. 

Adjusting system resources such as bufferpools, EDM pools, or work 
space, may provide 5% to 10% reductions in processing times of a 
query. Therefore, effort should be focused on tuning access paths to 
reduce resource consumption. 

P. 34. 

Chapter 5, "Establishing current system usage," discusses "how to 
gather the information needed to understand the characteristics of a business 
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intelligence workload" (p. 65). The chapter describes the three primary 
monitors (SMF, RMF, and DB2 PM). The SMF is described as follows: 

The OS/390 operating system includes the Systems Management 
Facility (SMF), which helps you measure various aspects of work 
running in the system. The component collects and records system- 
and job-related information that your installation can use to bill users, 
analyze the configuration, and perform capacity planning on system 
usage. 

SMF stores the information that is written by other applications, 
subsystems, and products into system-related SMF records (or job- 
related records). Most SMF records contain general identification 
fields such as the job name, step name, programmer name, start time, 
and start date. By sorting and summarizing SMF records according to 
these types of fields, an installation can create profiles that show the 
use of system resources by each unit of work, such as: 

• CPU time 

• Storage 

• I/O devices 

• Service units 
[Emphasis added.] 

Pp. 65-66. 

The Resource Management Facility (RMF) is described as containing 
"monitors that can be operated to collect and write data into SMF records 
(types 70-79)" (p. 66). "The RMF reports generated by the postprocessor 
are used for either capacity planning or performance tuning of an OS/390 
system." Id. For capacity planning, "[t]he Workload Activity Report shows 
workload-related data on resource consumption with different levels of 
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detail. It provides a summary by performance group (service class in goal 
mode), by reporting groups, and for the entire system." Id. 

IBM1 

IBM1 describes the RMF mentioned in Hahn in more detail. 

IBM1 describes that with Monitor III: "You can collect data that 
indicate how fast jobs or groups of jobs are running - this is called 
workflow or speed. You also can get data that show how resource-intensive 
jobs are using the processor, the DASD devices, and the storage." P. 1-2. 

IBM1 describes that in Monitor III, "[t]he Workflow/Exceptions 
(WFEX) report presents information about system activity and system 
resources" (p. 2-240). 

The WFEX report has two parts: "On the top Speed section, RMF 
reports the workflow of jobs and resources as speed relative to the maximum 
speed with which they could move through the system" and "On the bottom 
Exceptions section, RMF lists jobs, job groups, or system resources that 
meet exception criteria." P. 2-241. The WFEX report may be numerical, as 
shown in Figure 2-111, or graphical, as shown in Figure 2-112. 

The WFEX may be customized by defining or changing workflow 
indicators and exception conditions (p. 2-251). 

The WFEX may specify classes of resources, such as jobs, processor, 
device, etc. for workflow indicators (p. 2-252). 

The WFEX may specify an "alert" for an exception condition 
(p. 2-255). 
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DISCUSSION 

New arguments at oral hearing 

At the oral hearing, counsel for Appellants argued that the rejection 
did not comply with the requirements for anticipation in Net MoneyIN, Inc. 
v. Verisign, Inc., 545 F.3d 1359 (Fed. Cir. 2008). In particular, it was argued 
that Net MoneyIN requires that a prior art reference in order to anticipate 
must disclose all elements "arranged as in the claims" without any need for 
picking, choosing, and combining various disclosures not directly related to 
each other by the teachings of the reference. It was argued that the 
Examiner erred in finding anticipation by relying on the System 
Management Facility (SMF) for the step of gathering a statistic or data and 
relying on the Resource Management Facility (RMF) for the step of 
analyzing the statistic or data. Counsel stated that the RMF and SMF are 
separate monitors and the RMF does not operate on SMF data. It was 
acknowledged that this argument was not made in the Briefs, but it was 
argued that Net MoneyIN came out after the Briefs were filed. 

"Any arguments or authorities not included in the brief or a reply brief 
. . . will be refused consideration by the Board, unless good cause is shown." 
37 C.F.R. § 41.37(c)(l)(vii). "An exception to normal law of the case and 
waiver rules is recognized when an intervening decision from a superior 
court changes the controlling law." Beazer East, Inc. v. Mead Corp., 
525 F.3d 255, 263 (Fed. Cir. 2008). We do see that Net MoneyIN changes 
the law on anticipation so as to present good cause for allowing new 
arguments. Nevertheless, because we rely on the teachings of the references 
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for anticipation rather than the Examiner's particular statement of the 
rejection, the arguments are moot. 

Claims 1-8, 10-17, 19-26, and 29 
Issue 1 

Does IBM (as described by Hahn) teach "gathering at least one 
statistic or data related to the performance operation of the reporting system 
while the reporting system is operating"? 

Contentions 

Appellants argue that IBM is "not related to capturing statistics or data 
related to operation and/or performance of a report system" (Br. 9). It is 
argued that IBM measures statistics relating to the operating system, not a 
reporting system (id.). It is argued that "it is quite possible to have poor 
performance on a report while the underlying operating system, such as 
OS/390, is performing well and has low utilization" (id.; see also Reply 
Br. 4-5) and, thus, "it is quite evident that an alleged disclosure of operating 
system statistics is not disclosure of reporting system statistics" (Br. 9). 

Appellants further argue: 

The cited portions of Hahn are again directed, at most, to the alleged 
tracking of operating system statistics. For example, CPU time, 
storage, I/O Devices and service units are tracked. See, Hahn, 
pages 65-66. These are clearly operating system statistics and not 
reporting system statistics. An operating system is not a reporting 
system. 

Br. 10. 
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Appellants argue that there is no connection between an operating 
system gathering statistics and a reporting system that could enable the 
statistics gathering process to determine whether the statistics are related to 
reporting system performance and "Hahn and/or IBM1 would record 
statistics regardless of whether they were related to a reporting system and 
regardless of whether a reporting system were even installed" (Reply Br. 4). 
It is argued that "[t]here is no disclosure that the statistics gathered at the 
operating system of the Office's references will have any relation on the 
performance operation of the reporting system" (Reply Br. 5) 

Appellants argue that since IBM fails to disclose "gathering at least 
one statistic or data related to the performance operation of the reporting 
system" it certainly fails to disclose gather such statistics "while the 
reporting system is operating" in claim 1 (Reply Br. 5). 

Analysis 

We disagree with Appellants' argument that IBM does not relate to 
capturing statistics or data relating to the performance operation of a BI 
reporting system while the reporting system is operating. The whole 
disclosure of the IBM system is directed to measuring statistics and data of 
BI workload where "workload" refers to the BI application running on the 
system while it being used by the users, and where such a BI application 
may be a data analysis reporting system such as "Query and Reporting," 
"OLAP," and "Data mining" (p. 5). 



13 



Appeal 2009-0933 
Application 09/884,467 

Thus, Hahn's statement that "S/390 system measurement tools . . . can 
be utilized to capture the performance and resource consumption 
characteristics of the existing workload" (emphasis added) teaches 
"gathering at least one statistic or data related to the performance operation 
of the reporting system while the reporting system is operating" as recited in 
claim 1 because it is capturing performance and other data on the BI 
reporting system workload as it operates. Appellants' argument that IBM is 
measuring the performance of the operating system and not the BI reporting 
system (the workload) misapprehends the teachings of the references. 

As another example, Hahn discloses that capacity planning is focused 
on gathering information to answer, for example, the questions: "Which 
Information Technology (IT) resources are currently in use? (CPU, CF, 
devices, controllers, channels, coupling links, storages and so forth)" (p. 13) 
and "Which parts of the workloads consume the most resources" {id.). This 
clearly indicates that the data is being gathered about the performance 
operation of BI reporting system. Capacity planning is planning for the BI 
application capacity, not the bare operating system. 

Still further, Hahn discloses gathering profiles on the workload, data 
use associated with the application, the users, and on the queries (Sec. 4). 
All of these profiles deal with statistics and data on the BI reporting system 
while it is operating and therefore teach "gathering at least one statistic or 
data related to the performance operation of the reporting system while the 
reporting system is operating" as recited in claim 1. Figures 8 and 9, for 
example, show that the statistics and data gathered from the operation of the 
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BI application are "analyzed" as recited in the second step of claim 1 and are 
"output" as recited in the last step of claim 1. 

Hahn describes one tool to gather and analyze BI workflow data: 
"The OS/390 operating system includes the Systems Management Facility 
(SMF), which helps you measure various aspects of work running in the 
system. The component collects and records system- and job-related 
information that your installation can use to bill users, analyze the 
configuration, and perform capacity planning on system usage." P. 65. 
Hahn disclose that the SMF "can create profiles that show the use of system 
resources by each unit of work, such as: [CPU time, Storage, I/O device, and 
Service units]" (id.). This further describes "gathering at least one statistic 
or data related to the performance operation of the reporting system while 
the reporting system is operating." 

Separate from the SMF is the Resource Management Facility (RMF), 
which can generate reports "for either capacity planning or performance 
tuning of an OS/390 system" (p. 66). "The Workload Activity Report shows 
workload-related data on resource consumption with different levels of 
detail. It provides a summary by performance group (service class in goal 
mode), by reporting groups, and for the entire system." Id. IBM1 describes 
that "[t]he Workflow/Exceptions (WFEX) report presents information about 
system activity and system resources" (p. 2-240), including a Speed section 
which "reports the workflow of jobs and resources as speed relative to the 
maximum speed with which they could move through the system" (p. 2-241) 
and an Exceptions section which "lists jobs, job groups, or system resources 
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that meet exception criteria" (id.). The WFEX may specify an "alert" for an 
exception condition (p. 2-255). The RMF gathers, analyzes, and outputs 
data, statistics, and exceptions about the operation of the BI workload in the 
WFEX report and thus further describes "gathering at least one statistic or 
data related to the performance operation of the reporting system while the 
reporting system is operating." 

Conclusion 

IBM teaches "gathering at least one statistic or data related to the 
performance operation of the reporting system while the reporting system is 
operating." 

Issue 2 

Does IBM teach "capturing at least one statistic or data regarding 
performance operation of a business intelligence reporting system that 
generates business intelligence reports based on requests submitted to 
perform analysis of data contained in a database"? 

Contentions 

Appellants argue that the Systems Management Facility (SMF) 
"reports of Hahn relied upon by the Examiner, appear to run as a default part 
of the operating system" (Br. 10; see also Reply Br. 7). It is noted that the 
SMF "helps you measure various aspects of work running in the system" 
(Hahn, p. 65) and Appellants argue that a process run as a default part of the 
operating system does not capture data of a BI reporting system that 
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generates BI reports "based on requests submitted to perform analysis of 
data" as recited in claim 1 (Br. 10; see also Reply Br. 7-8). 

Appellants argue (Reply Br. 6) that the Examiner errs in interpreting 
that "based on requests submitted to perform analysis of data" in the 
preamble of claim 1 "refers to the user requests to generate business 
intelligence reports" (Ans. 14) and does not require "a user to request 
'analysis of data' before any statistics and/or data regarding performance 
operation of a business intelligence reporting system is captured" {id.). It is 
argued that "the logical interpretation is that once the request is received, the 
data is gathered and then analyzed" (Reply Br. 6). 

Analysis 

We agree with Appellants that "capturing at least one statistic or data 
. . . based on requests submitted to perform analysis of data contained in a 
database" means that statistics or data are gathered while the BI reporting 
system is operating in response to requests by users. However, as discussed 
in connection with Issue 1, IBM is directed to measuring characteristics of a 
BI workload, in particular, a reporting application workload where users are 
submitting requests to perform analysis of data in a database, i.e., as the BI 
reporting application is operating. Appellants' arguments that the IBM 
system discussed in Hahn is not capturing data on the performance of the 
reporting system as it is operating is not persuasive as discussed in Issue 1. 
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Conclusion 

IBM teaches "capturing at least one statistic or data regarding 
performance operation of a business intelligence reporting system that 
generates business intelligence reports based on requests submitted to 
perform analysis of data contained in a database." 

Conclusion 

Appellants have not demonstrated error in the anticipation rejection of 
claim 1. The claims are not argued separately. Accordingly, the rejection of 
claims 1-8, 10-17, 19-26, and 29 is affirmed. 

Claims 9, 18, and 27 

Appellants argue that Hayes fails to cure the deficiencies as to the 
rejection of the independent claims (Br. 11-12; Reply Br. 8-9). 

We find that there are no deficiencies in the rejection of the 
independent claims. 

Appellants argue that IBM1 and Hahn do not teach or suggest tuning a 
report system, but are directed towards an operating system (Br. 11). 

We disagree. As discussed in connection with Issue 1 in the 
anticipation rejection, IBM is directed to measuring the performance 
characteristics of a BI reporting system as it is operating. Hahn describes 
that the BI reporting application may be "tuned" to increase performance 
(pp. 33-34); e.g., "[w]ith proper tuning, it is not unusual to reduce a query 
from hours of elapsed time to completion in minutes" (p. 33). Such tuning 
must be based on the output of the data/statistic gathering and analysis 
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output, such as the time to complete a query. Hahn describes "[a]djusting 
[i.e., tuning] system resources such as bufferpools," but does not teach is 
"performing automated tuning" (emphasis added). 

Hayes describes "a method for automating database bufferpool tuning 
for optimized performance that employs certain heuristic algorithms to 
achieve its goals" (Abstract). We agree with the Examiner's conclusion that 
Hayes would have motivated one of ordinary skill in the art to automate the 
tuning of a system resource such as the bufferpool in Hahn. 

Appellants argue that an operation performed on a reporting system is 
not disclosed by an operation on a lower level process such as an operating 
system or database cache, that database bufferpool tuning is applicable only 
to databases which have bufferpools, and not all databases may have 
bufferpools and tuning a bufferpool may not address any issues of a report 
system (Br. 12). 

Hahn describes tuning to increase the performance of the reporting 
system and one system resource to be tuned is the bufferpool. Appellants' 
arguments that Hahn does not tune the reporting system are not persuasive. 
The fact that not all databases have bufferpools is not persuasive since Hahn 
describes tuning of the bufferpool to increase BI system performance. 

Appellants argue that that claim 9 recites the automated tuning is 
based on an output, wherein the output is based on requests submitted to 
perform analysis of data, and the alleged automated tuning of Hayes is not 
based upon an output which is based on requests submitted to perform 
analysis of data (Br. 12-13). 
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Hahn teaches that tuning is based on measurement of system 
performance characteristics and resources (the output). Hayes describes that 
memory (bufferpool) performance is measured over time and used for 
automated database bufferpool tuning (Abstract), so it performs bufferpool 
tuning based on operation of the application, whatever that application 
happens to be. Appellants have not offered any explanation of how Hayes 
could automatically tune the bufferpool if it was not based on the output of 
measured data from the operating application. One of ordinary skill in the 
art would have been motivated to perform automated tuning in Hahn in view 
of the express teachings in Hayes, where the tuning in both Hahn and Hayes 
is based on data gathered during operation of the BI reporting system. 

We conclude that Appellants have not shown error in the rejection of 
dependent claims 9, 18, and 27. The rejection of claims 9, 18, and 27 is 
affirmed. 

CONCLUSION 
The rejections of claims 1-27 and 29 are affirmed. 
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Requests for extensions of time are governed by 37 C.F.R. § 1.136(b). 
See 37 C.F.R. § 41.50(f). 

AFFIRMED 
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